Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-004.txt

Text File | 1992-11-18 | 58.9 KB | 1,602 lines | [TEXT/MPS ]

C.S.M.P. Digest             Sun, 08 Mar 92       Volume 1 : Issue 4

Today's Topics:

    CTB tool resource access
    Question on useritems in dialogs
    Regions
    gambit scheme interpreter
    C++ for mac (for beginner)
    Standard UI question regarding tool pallettes.
    moving resources from point A to point B?
    Status of MacTutor
    drawing dash lines in QuickDraw...
    Finding all mounted volumes
    68040 caches, why do programs break?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac directory on ftp.cs.uoregon.edu.
This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Miika Asunta)
Subject: CTB tool resource access
Date: 26 Jan 92 10:32:07 GMT
Organization: Finnish Academic and Research Network Project - FUNET

There is one missing piece of documentation in Inside Comm TB.

    HOW DO I ACCESS RESOURCES?
    HOW DO I AVOID CONFLICTS WITH TERMINAL APP'S RESOURCES?

Communications Resource Manager defines few routines, which are helpful
but how to access DLOGs and ALERTs with routines

GetNewDialog()
Alert()


Chapter 'Writing Connection tools' gives a following hint in a code sample

{
int oldresfile=CurResFile();
UseResFile((**Transfer).procID);
// access resources here
UseResFile(oldresfile);
}

Which doesn't feel like best solution.
And, nothing is said in the documentation.

Do CRMRealToLocalID and CRMLocalToRealID check possible conflicts?

And, why ctb source code samples are not in ftp.apple.com?

Miika


--
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&  Miika Asunta        &  [e-mail]  &  Double Bass Player   &
& tel. [phone]  &             &  Macintosh Programmer &
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&



- -------------------------

From: [e-mail]
Subject:  CTB tool resource access
Date: 26 Jan 92 19:06:37 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Miika Asunta) writes:
>There is one missing piece of documentation in Inside Comm TB.
>
>    HOW DO I ACCESS RESOURCES?
>    HOW DO I AVOID CONFLICTS WITH TERMINAL APP'S RESOURCES?
>
>Chapter 'Writing Connection tools' gives a following hint in a code sample
>
>{
>int oldresfile=CurResFile();
>UseResFile((**Transfer).procID);
>// access resources here
>UseResFile(oldresfile);
>}
>
>Which doesn't feel like best solution.
>
    Believe it or not, that is the correct solution!  That will give you
access to your resources, and you should NEVER have to worry about conflicting
with application resources since the tool's resource map goes into the chain
BEHIND the System - so there is a LOT of stuff that a GetResource call would
find first on a normal search.

>And, nothing is said in the documentation.
>
    What else is new ;-)


--
- ---------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician



---------------------------

From: [e-mail] (Mengyik Yeong)
Subject: Question on useritems in dialogs
Date: 26 Jan 92 18:25:18 GMT

I am trying to write a dialog routine with a userItem, but am having some
trouble with it.  Any help would be greatly appreciated.

I installed my useritem procedure with calls to the GetDItem and SetDItem
functions.  My useritem function is called from ModalDialog and does what
it is supposed to do.  However, the program hangs upon exiting from my
useritem function.  In addition, although the userItem function is called,
the 'theItem' parameter which is passed is wrong, ie not what is passed
by SetDItem.  I had assumed originally that the useritem procedure would
be called by the ShowWindow routine, since that is what displays the dialog
items.  Why is it called by ModalDialog?  I would really appreciate any
help on this matter.  Do I need to write a custom filterProc routine?
My userItem function only does some custom drawing to the dialog box and does
not take any input from the user.

Thanks in anticipation

Mengyik
[e-mail]



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  Question on useritems in dialogs
Date: 28 Jan 92 01:20:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Mengyik Yeong) writes:
>I am trying to write a dialog routine with a userItem, but am having some
>trouble with it.  Any help would be greatly appreciated.

>I installed my useritem procedure with calls to the GetDItem and SetDItem
>functions.  My useritem function is called from ModalDialog and does what
>it is supposed to do.  However, the program hangs upon exiting from my
>useritem function.  In addition, although the userItem function is called,
>the 'theItem' parameter which is passed is wrong, ie not what is passed
>by SetDItem.  I had assumed originally that the useritem procedure would
>be called by the ShowWindow routine, since that is what displays the dialog
>items.  Why is it called by ModalDialog?  I would really appreciate any
>help on this matter.  Do I need to write a custom filterProc routine?
>My userItem function only does some custom drawing to the dialog box and does
>not take any input from the user.

First make sure that you installed your userItem correctly.  The code should
look something like this:

    GetDItem(theDialog,theItem,&theType,&theHandle,&theRect);
    SetDItem(theDialog,theItem,theType,(ProcPtr)&DrawUserItem);

where DrawUserItem is defined as:

    pascal void DrawUserItem(DialogPtr theDialog, short theItem)

Assuming your drawing code doesn't do anything weird, the above should work.

You are mistaken about when the drawing takes place.  ShowWindow does not draw
the contents of your window; it simply makes your window visible (if it was
previously invisible).  ModalDialog will cause your window's contents to be
drawn (or re-drawn) in response to an update event generated when your window
requires an update.  You don't need a special filterProc to handle the
drawing, since filterProcs _typically_ are used for filtering events...

steve
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



- -------------------------

From: [e-mail] (Mengyik Yeong)
Subject:  Question on useritems in dialogs
Date: 28 Jan 92 15:14:04 GMT

Thanks to all who responded to my question. Turns out my mistake was
I did not declare my userItem function as a pascal function.

Mengyik



- -------------------------

From: [e-mail] (Nicholas Jackiw)
Subject:  Question on useritems in dialogs
Date: 30 Jan 92 19:04:05 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]> [e-mail] (Mengyik Yeong) writes:
>
>I installed my useritem procedure with calls to the GetDItem and SetDItem
>functions.  My useritem function is called from ModalDialog and does what
>it is supposed to do.  However, the program hangs upon exiting from my
>useritem function.  In addition, although the userItem function is called,
>the 'theItem' parameter which is passed is wrong, ie not what is passed
>by SetDItem.  I had assumed originally that the useritem procedure would
>be called by the ShowWindow routine, since that is what displays the dialog
>items.  Why is it called by ModalDialog?  I would really appreciate any
>help on this matter.  Do I need to write a custom filterProc routine?
>My userItem function only does some custom drawing to the dialog box and does
>not take any input from the user.

You should post your code to clarify what's going wrong with your
GetDItem/SetDItem (i. e. why theItem is incorrect on invocation of
your userProc.

As to why it's called by ModalDialog instead of ShowWindow, understand
that ShowWindow draws only the window structure (i. e. frame, titlebar).
The contents of the window are added to the window's updateRgn, which is
then reported as non-empty by an updateEvent.  ModalDialog, which is a
private GetNextEvent loop, receives the update event and calls DrawDialog.
DrawDialog iterates through your items and, upon realizing that your
user item intersects the update region, calls your user item proc.  On the
other hand, if theItem is incorrect, then it's not looking at your user
item at all, but at some other item.  Posting your code will help us
figure out why.


--
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---



---------------------------

From: [e-mail] (Donna Foster)
Subject: Regions
Date: 26 Jan 92 19:48:50 GMT
Organization: University of Maine System

My SO asked me to pass on this query. He's defining a game board with ~60
hexagons so that he can use PtInRgn (?) to find where the user clicked.
However, this seems to be a huge memory hog. Can anyone confirm this? Also,
is there any way in ThinkC to keep track of current memory allocation? If
not, this might be nice for a future release.... TIA :-)



- -------------------------

From: [e-mail] (Nicholas Jackiw)
Subject:  Regions
Date: 30 Jan 92 19:21:08 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

In article <[e-mail]> [e-mail] (Donna Foster) writes:
>My SO asked me to pass on this query. He's defining a game board with ~60
>hexagons so that he can use PtInRgn (?) to find where the user clicked.
>However, this seems to be a huge memory hog. Can anyone confirm this? Also,
>is there any way in ThinkC to keep track of current memory allocation? If
>not, this might be nice for a future release.... TIA :-)

"To keep track of current memory allocation"

What do you mean, exactly?  You might try looking at FreeMem in the
memory manager, if you're simply after a byteCount of available space.

Re Regions

GROSSLY INEFFICIENT:

60 regions, identical (congruent) in form, situated at different origins.

INEFFICIENT:

1 region describing a canonical hexagon.  Use OffsetRgn to move it to
origin#x (0<x<~60) before checking if PtInRgn(myPt,CanonicalRgn) is true.
If it is, myPt is in hexagon #x.

Efficient because OffsetRgn is very fast; most of a region is origin-relative,
and OffsetRgn just moves the origin.

Inefficient because regions' structure is designed to best accomodate
unions of overlapping rectangles in standard orientation (e. g. a bunch
of overlapping windows).  Hexagons, which must include some diagonal
lines, are very difficult to describe by overlapping rectangles.

MOST EFFICIENT:

Exploit any symmetries in your board and answer the question arithmetically.
If your hexes are regular, you should be able to devise a simple integer
expression to determine point inclusion.  Better, if your hexes are laid in
a regular grid, think of that grid as the intersection of three perfectly
square grids (at 120 angles to each other), which can be solved by straight
division.


--
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Regions
Date: 1 Feb 92 06:14:33 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Nicholas Jackiw) writes:

> INEFFICIENT:
>
> 1 region describing a canonical hexagon.  Use OffsetRgn to move it to
> origin#x (0<x<~60) before checking if PtInRgn(myPt,CanonicalRgn) is true.
> If it is, myPt is in hexagon #x.
>
> Efficient because OffsetRgn is very fast; most of a region is origin-relative,
> and OffsetRgn just moves the origin.

No it isn't. I know IM1 (or something official from way back) says that a
region is origin-relative, but it most certainly is not. OffsetRgn really
does require modifying every point coordinate in the region structure.

A full description of the QuickDraw region structure can be found in Ted
Cohn's article in MacTutor from a couple or so years back (drat, I forget
the exact issue).

> Inefficient because regions' structure is designed to best accomodate
> unions of overlapping rectangles in standard orientation (e. g. a bunch
> of overlapping windows).  Hexagons, which must include some diagonal
> lines, are very difficult to describe by overlapping rectangles.

Damn right.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
X Windows: distributed computing in reverse.



- -------------------------

From: [e-mail] (Globulator)
Subject:  Regions
Date: 31 Jan 92 05:52:20 GMT
Organization: University of Illinois at Urbana

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>No it isn't. I know IM1 (or something official from way back) says that a
>region is origin-relative, but it most certainly is not. OffsetRgn really
>does require modifying every point coordinate in the region structure.

Say it ain't so!  Hmmm...how can this be, seeing as a QuickDraw region
is just a set of inversion points, defined from whatever rgnBBox.topLeft
is?  No point information...just inversion information.  Or is what I
understand the region definition to be completely flawed?
--
Tim McClarren ([e-mail])|"I'm countin' down to the day deservin'
Mac Programmer  [phone]     | Fittin' for a king  I'm waitin' for the
NCSA/STG@University of Illinois   | time when I can Get to Arizona" PE Apoc 91



- -------------------------

From: [e-mail] (Christer Ericson)
Subject:  Regions
Date: 31 Jan 92 16:11:34 GMT
Organization: Dep. of Info.Proc, Umea Univ., Sweden

In <[e-mail]> [e-mail] (Globulator) writes:

>[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>>No it isn't. I know IM1 (or something official from way back) says that a
>>region is origin-relative, but it most certainly is not. OffsetRgn really
>>does require modifying every point coordinate in the region structure.
>
>Say it ain't so!  Hmmm...how can this be, seeing as a QuickDraw region
>is just a set of inversion points, defined from whatever rgnBBox.topLeft
>is?  No point information...just inversion information.  Or is what I
>understand the region definition to be completely flawed?

No, only somewhat flawed. Regions are handled in two cases, rectangular
and not rectangular. If a region is rectangular it will only consist
of the size (being ten) and the rect itself. If not, the rect will
be followed by the inversion point data. This is organized in scanlines
of the format (XXXX and YYYY are words)

YYYY XXXX XXXX .... XXXX XXXX  7FFF
YYYY ....
7FFF

These are not in any way related to the bounding rect, so OffsetRgn
will have to update every point in the region, which can be seen from
inspecting the code. Inspecting the code will also reveal something
else, which might or might not be obvious; that in a non rectangular
region there must be at least one scanline, and that the x coordinates
of the scanline always come in pairs.

For those not familiar with reading ROM code, I've appended it below
with some annotations of mine. It is really short, and since everyone
will be able to find it in their own ROM using Macsbug I hope
Apples lawyers won't jump on me for including it. IMHO, it is an
excellent piece of code to learn the region format from.

  _OfsetRgn
     +0000  408361E0   MOVEA.L    (A7)+,A1    ;fetch return address
     +0002  408361E2   MOVE.W     (A7)+,D1    ;and dv
     +0004  408361E4   MOVE.W     (A7)+,D0    ;and dh
     +0006  408361E6   MOVEA.L    (A7)+,A0    ;and pointer to rgn
     +0008  408361E8   MOVEA.L    (A0),A0
     +000A  408361EA   ADDQ.W     #$2,A0    ;skip rgnSize
     +000C  408361EC   ADD.W      D1,(A0)+    ;now offset rgnBBox
     +000E  408361EE   ADD.W      D0,(A0)+    ;using dv & dh
     +0010  408361F0   ADD.W      D1,(A0)+
     +0012  408361F2   ADD.W      D0,(A0)+
     +0014  408361F4   CMPI.W     #$000A,-$000A(A0);is rgn rectangular?
     +001A  408361FA   BEQ.S      _OfsetRgn+0030;yes, we're done
     +001C  408361FC   ADD.W      D1,(A0)+    ;update y coord
     +001E  408361FE   ADD.W      D0,(A0)+    ;update pair of
     +0020  40836200   ADD.W      D0,(A0)+    ;x coord inversion points
     +0022  40836202   CMPI.W     #$7FFF,(A0)    ;repeat for all inversion
     +0026  40836206   BNE.S      _OfsetRgn+001E;points of scanline
     +0028  40836208   ADDQ.W     #$2,A0
     +002A  4083620A   CMPI.W     #$7FFF,(A0)    ;repeat for all
     +002E  4083620E   BNE.S      _OfsetRgn+001C;rows in rgn
     +0030  40836210   JMP        (A1)        ;return to caller


Christer Ericson --- Internet: [e-mail] --- tel: [phone]
Department of Computer Science, University of Umea, S-90187 UMEA, SWEDEN



- -------------------------

From: [e-mail] (Jess M Holle)
Subject:  Regions
Date: 31 Jan 92 20:38:24 GMT
Organization: Purdue University Engineering Computer Network

Another idea for checking whether a point is in a polygon, in general, assuming
that you have convex polygon is:

Take the dot product (using integer math) of
  - the vector from each polygon point to the next
and
  - the vector from each polygon point to the mouse click location

By examining the signs of these dot products, you can decide whether the
point is in or out of the polygon.  Quick rejection should be applied so
that if the point is found to be outside of the polygon on the first test,
it skips out of the check loop immediately.  With a little optimization
for your polygons and a quick check to find which polygons are even worth
checking (for example, if the polygons all fit within a 20 pixel rectangle,
only check polygons known to be close enough to the pick point), this routine
should be relatively quick.

This was probably already been obvious.  For this application, one of the other
techniques mentioned may work better, I'm just throwing out an idea.

Jess Holle



- -------------------------

From: [e-mail] (Douglas Muller)
Subject:  Regions
Date: 1 Feb 92 02:51:04 GMT
Organization: Oregon State University, Computer Science Dept.

Instead of offsetting the region why don't you offset the point
in the opposite directions?

Am I missing something?

[e-mail]

If I could afford my own .sig you would see it here!



- -------------------------

From: [e-mail] (Greg L. Anderson)
Subject:  Regions
Date: 31 Jan 92 21:17:49 GMT
Organization: Apple Computer Inc., Cupertino, CA

>[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>>No it isn't. I know IM1 (or something official from way back) says that a
>>region is origin-relative, but it most certainly is not. OffsetRgn really
>>does require modifying every point coordinate in the region structure.

In article <[e-mail]> [e-mail] (Globulator) writes:
>Say it ain't so!

It's so.

>Hmmm...how can this be, seeing as a QuickDraw region
>is just a set of inversion points, defined from whatever rgnBBox.topLeft
>is?  No point information...just inversion information.  Or is what I
>understand the region definition to be completely flawed?

Quickdraw regions are sets of inversion points all right, but the
points are specified in quickdraw-space, not relative to any part
of the bounding box.
--
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Developer Tools Engineering    O O  is  ideal  O O
[e-mail]       Apple Developer Suite           O     shape     O
=====================   ===========================   =====================



---------------------------

From: [e-mail] (wonko the sane)
Subject: gambit scheme interpreter
Date: 27 Jan 92 01:31:59 GMT
Organization: Colorado State U. Engineering College


  I was wondering if anyone out there had played with the Gambit scheme
  interpreter v1.7.  I am having real problems even getting it to add two
  numbers together.  Is there any trick to getting it to read the input?
  I spent about two hours with it and I got 3*5 to work once by accident
  and never did figure out how I did it.

  Any help would be appreciated!

              -------> Larry Loesch <-------

              [e-mail]



- -------------------------

From: [e-mail] (Zach Kessin)
Subject:  gambit scheme interpreter
Date: 27 Jan 92 03:18:05 GMT
Organization: Brandeis University

[e-mail] (wonko the sane) writes:


>  I was wondering if anyone out there had played with the Gambit scheme
>  interpreter v1.7.  I am having real problems even getting it to add two
>  numbers together.  Is there any trick to getting it to read the input?
>  I spent about two hours with it and I got 3*5 to work once by accident
>  and never did figure out how I did it.

>  Any help would be appreciated!

>              -------> Larry Loesch <-------

>              [e-mail]

You nead to hit the <enter> key (on the keypad) to send something to
the interpreter. if you do that even in the editor window it will
work.

==>(+ 3 5) <enter>
8

--Zach

   Zachary Kessin                /  recursive: adj, see recursive
 [e-mail]  /
 Kessin@brandeis (BITNET)      /    I have not lost my mind:
 [phone]                /       I have a tape backup somewhere



- -------------------------

From: [e-mail] (Patrick Logan)
Subject:  gambit scheme interpreter
Date: 27 Jan 92 20:21:34 GMT
Organization: Mentor Graphics Corporation

In article <[e-mail]> [e-mail] (wonko the sane) writes:
     I was wondering if anyone out there had played with the Gambit scheme
     interpreter v1.7.  I am having real problems even getting it to add two
     numbers together.  Is there any trick to getting it to read the input?
     I spent about two hours with it and I got 3*5 to work once by accident
     and never did figure out how I did it.

     Any help would be appreciated!

Read the "read me first" (or similarly named file). Place the text
cursor behind the expression to be evaluated then type the <enter>
key.

<newline> will advance the text cursor to a new line following the
current line. <enter> will evaluate the expression preceding the text
cursor.

--
Patrick Logan, [e-mail],
Voice: [phone] x2907, FAX: [phone]
Mentor Graphics Corp., Bldg. C, 8005 SW Boeckman Rd., Wilsonville, OR 97070
I can't gete the .signature virus and I can't gete the .signature



---------------------------

From: [e-mail] (Zach Kessin)
Subject: C++ for mac (for beginner)
Date: 27 Jan 92 01:11:37 GMT
Organization: Brandeis University

I am looking to learn C++ and I am trying to figure out which c++
would be best. please consider both price and features

thanks

--Zach

   Zachary Kessin                /  recursive: adj, see recursive
 [e-mail]  /
 Kessin@brandeis (BITNET)      /    I have not lost my mind:
 [phone]                /       I have a tape backup somewhere



- -------------------------

From: [e-mail] (Blair M. Burtan)
Subject:  C++ for mac (for beginner)
Date: 27 Jan 92 22:44:34 GMT
Organization: Boston U. College of Engineering

>From what I can tell, MPW is the only full-blown C++ out there.

Now here's a really good question/request:

   Could someone (i.e. Apple) please write a version
   of Inside Macintosh with C prototypes?  Having learned
   Mac programming in Pascal, I need to know the equivalents in C.
   I have torn my hair out many times trying to figure out
   whether something should be a pointer or not and mundane things
   like what is the equivalent to Str255.  EEEEEEEEEEEEEK!!!!!!

   We now return you to your regularly scheduled news reader...
--
+---------------------------------------+
+ "If it isn't Baroque, don't fix it."  +
+               - Beauty and The Beast  +
+                        +
+ Blair M. Burtan: [e-mail]    +
+                  [e-mail]   +
+---------------------------------------+



---------------------------

From: [e-mail] (Phil Trubey)
Subject: Standard UI question regarding tool pallettes.
Date: 27 Jan 92 06:11:29 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

When an application has a floating tool palette (like the one in MacPaint),
the tool selected can be global for all open documents, or its state can
change depending which document is active.  I've seen different applications
implement this in the two different ways.  MacPaint, for instance, has the
tool palette selection global to the entire application so that if you
click on the font tool while operating on one document, clicking on another
document will keep the font tool selected.

Other applications do it the other way round and keep track of which
tool is selected for each open document.

The current font type and style are other examples of things that can be global
to the application or just global to the open documents.

My question is:  is there a standard for which way to design your application?
Or do the Apple UI police ( :-) ) not care?

--
Phil Trubey                   | [e-mail]
Systemhouse Inc.              | 415-243-8100 (day)



- -------------------------

From: [e-mail] (Mark Lanett)
Subject:  Standard UI question regarding tool pallettes.
Date: 27 Jan 92 14:59:28 GMT
Organization: University of Illinois at Urbana

[e-mail] (Phil Trubey) writes:

>When an application has a floating tool palette (like the one in MacPaint),
>the tool selected can be global for all open documents, or its state can
>change depending which document is active.  I've seen different applications
>implement this in the two different ways.  MacPaint, for instance, has the
>tool palette selection global to the entire application so that if you
>click on the font tool while operating on one document, clicking on another
>document will keep the font tool selected.

If you play with ResEdit for a while you'll quickly get annoyed by it's use
of separate tool palettes. In my program each kind of document shares the
tool palette, but there are still 3 kind of documents/tool palettes. I'm goinf
to change it so that the contents of a single tool palette always show what's
appropriate for the document.
--
Mark Lanett                                                   [e-mail]
Software Tools Group, NCSA, University of Illinois at Urbana-Champaign



- -------------------------

From: [e-mail] (Eric W. Douglas)
Subject:  Standard UI question regarding tool pallettes.
Date: 27 Jan 92 14:37:38 GMT


[e-mail] (Phil Trubey) writes:

>When an application has a floating tool palette (like the one in MacPaint),
>the tool selected can be global for all open documents, or its state can
>change depending which document is active.  I've seen different applications
>implement this in the two different ways.  MacPaint, for instance, has the
>tool palette selection global to the entire application so that if you
>click on the font tool while operating on one document, clicking on another
>document will keep the font tool selected.

>Other applications do it the other way round and keep track of which
>tool is selected for each open document.

>The current font type and style are other examples of things that can be global
>to the application or just global to the open documents.

>My question is:  is there a standard for which way to design your application?
>Or do the Apple UI police ( :-) ) not care?

I would say there is no defacto fashion for implementation, since apple
officially doesn't tell programmer's how to implement tool palletes.

IMO, the "user intuitiveness" of the palettes which identify with whatever
window is currently active are much better. One point which you must be
aware of though, are instances where a user will do a clipboard operation
on one layer, then paste the selection into another layer. In this instance,
the current tool in the destination layer should switch to whatever tool
is appopriate for the operation. In the case of the clipboard, it would
probably be the pointer tool, so that the user may move around the pasted
object.

--eric

* | Eric W. Douglas             Technojock               [phone] | *
* | I'net: [e-mail]      [e-mail] | *
* | AppleLink: STUDIO.D      Compuserve: 76170,1472       AOL: EWDOUGLAS | *
____________________________________________________________________________



---------------------------

From: [e-mail] (Roby Sherman)
Subject: moving resources from point A to point B?
Date: 27 Jan 92 14:08:29 GMT
Organization: The Tao of Programming

Hi.

   I'm working on a program that will open the resource of a file and modify
   it's resources (ICONS, SND, etc) I was wondering what would be the BEST
   method for copying the resources from one to the other... I have two
   scenarios that I've looked at :

   1> Load Resource A, Load Resource B copy contents of handle A to Handle
   B, Call CHANGEDRESOURCE on handle B, WriteResource B


   2>Remove resource B, Load Resource A, Add Resource A to RESFILE B.

   Any ideas on how I can do this better?


      --Roby
--
[e-mail]                    Roby Sherman



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  moving resources from point A to point B?
Date: 27 Jan 92 15:41:39 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] (Roby Sherman) writes:
>Hi.
>
>   I'm working on a program that will open the resource of a file and modify
>   it's resources (ICONS, SND, etc) I was wondering what would be the BEST
>   method for copying the resources from one to the other... I have two
>   scenarios that I've looked at :
>
>   1> Load Resource A, Load Resource B copy contents of handle A to Handle
>   B, Call CHANGEDRESOURCE on handle B, WriteResource B
>
>
>   2>Remove resource B, Load Resource A, Add Resource A to RESFILE B.
>
>   Any ideas on how I can do this better?

I believe scenario 1> is preferable, as scenario 2> involves everything
scenario 1> involves, plus unnecessary change to the resource map.


--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Status of MacTutor
Date: 27 Jan 92 23:32:59 GMT
Organization: University of Waikato, Hamilton, New Zealand

You may recall my posting a week or two back reporting subscription problems
with MacTutor magazine, and asking if anyone else had been having similar
troubles.

Thanks to all those who replied via e-mail with information about the
change of ownership and contact information. I thought I'd post a summary
of developments, for those who are curious.

The story is, MacTutor have been acquired by Xplain Corp. Here's a copy
of the press release that was sent to me:

****
News Release -- For Immediate Release

Los Angeles, California, January 11th, 1992 -- Xplain Corporation today
announced that it has acquired MacTutor Company.  For more than 7 years,
MacTutor Company has published MacTutor Magazine -- The Macintosh Programming
Journal.  For more than 5 years, Xplain's principles have specialized in
software development, technical writing and software sales.

Xplain will be moving the magazine from it's Anaheim, California location to
West Los Angeles, California.  To accomodate moving and acquisition activities
as well as changes in the magazine, MacTutor is taking a short hiatus.  The
next issue will be either March or April.  All current subscribers and
advertisers will get automatic extensions so as not lose any issues.

Xplain will be using a combination of existing and new staff to provide even
better services to the Macintosh Developer community.  In future issues, the
magazine will address an even broader range of programmers, and development
topics.  Among the changes will be increased development-related product
reviews and far greater reader feedback.
****

This was part of a very courteous reply I received from Neil Ticktin,
president of Xplain, in response to a message I sent to their AppleLink
address. I was told that they know of a problem with some international
subscribers not getting their November issues, and that they were sorting
this out.

For those looking to get in touch with MacTutor, here's the new contact
information:

    MacTutor Magazine
    P.O. Box 250001
    Los Angeles, CA 90025-250001
    Voice: 310-575-4343
    Fax: [phone]
    AppleLink: MACTUTOR
    (via Internet: [e-mail])

(By the way, is that ZIP code number really correct?? I thought they only
went up to 9 digits...) According to the message, they "love" AppleLink,
and they're obviously not averse to responding to Internet mail messages
either. They're also promising earlier deliveries in future.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
X Windows: distributed computing in reverse.



- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  Status of MacTutor
Date: 30 Jan 92 17:01:59 +1300
Organization: University of Waikato, Hamilton, New Zealand

An update to my message about MacTutor: I just received a mail message
saying the post office has decided to change their P O box number!

Here's the new contact information:

    MacTutor Magazine/Xplain Corp.
    P.O. Box 250055
    Los Angeles, CA 90025-250055
    Voice: 310-575-4343
    Fax: [phone]
    AppleLink: MACTUTOR

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
X Windows: distributed computing in reverse.



---------------------------

From: [e-mail] (Herve Trognon)
Subject: drawing dash lines in QuickDraw...
Date: 28 Jan 92 01:43:04 GMT
Organization: Oregon State University, Computer Science Dept.

Hello,

Is there any way to draw a dash line in quickdraw or do we have to implement it ourselves - and then how?

Thanks
Gribouille.



- -------------------------

From: [e-mail] (Thomas Alan Akins)
Subject:  drawing dash lines in QuickDraw...
Organization: /local/lib/rn/organization
Date: Tue, 28 Jan 1992 05:46:50 GMT

After pouring over Inside Macintosh, I couldn't find any Toolbox routines that
draw dashed lines.  The SRGP package does have:

    SRGP_setLineStyle(lineStyleType);

    where lineStyleType = {CONTINUOUS, DASHED, DOTTED, DOT_DASHED}

But, for your own purposes, Inside Mac says you can override the built-in low-
level line drawing routine with one of your own.  You therefore need to come up
with a routine that will turn on pixels for a certain number of pixels (PenMode
set to patCopy or 8) and then draws without turning on pixels (PenMode set to a
negative number).

In order to use this routine as a standard (ie override the Toolbox StdLine
routine.) StdLine(newPt: Point) draws to the point specified by newPt.
Your routine could take other arguments (line the SRGP routine) to specify
the line style.  Or have a series of routines for each line style and use
SetStdProcs(VAR procs: QDProcs) where:

    QDProcs = RECORD
            textProc:    Ptr; {text drawing}
            lineProc:    Ptr; {line drawing}
                <blah>
                  .
                  .

    Change the lineProc pointer to point to the line-drawing routine you
need to draw the line style of your choice.

There are a lot of possibilities, most of which involve a good deal of
programming on your part.

If anyone else has better ideas (I know there are much better ideas) please
post them as I am quite the novice to Mac programming and would love to find
some shortcuts for this kind of thing.
                            _    _
--
*                                            Alan Akins                      *
*       "I could say 'addition'              [e-mail]            *
*        when I mean ... 'basketball.'"      University of Oregon            *
*                        - E. Tick           Department of Computer Science  *



- -------------------------

From: [e-mail] (Keith Warren Rickert)
Subject:  drawing dash lines in QuickDraw...
Date: 28 Jan 92 06:53:36 GMT
Organization: California Institute of Technology, Pasadena

In article <[e-mail]> [e-mail] (Thomas Alan Akins) writes:
>After pouring over Inside Macintosh, I couldn't find any Toolbox routines that
>draw dashed lines.  The SRGP package does have:
>
>    SRGP_setLineStyle(lineStyleType);
>
>    where lineStyleType = {CONTINUOUS, DASHED, DOTTED, DOT_DASHED}
>
>But, for your own purposes, Inside Mac says you can override the built-in low-
>level line drawing routine with one of your own.  You therefore need to come up
>with a routine that will turn on pixels for a certain number of pixels (PenMode
>set to patCopy or 8) and then draws without turning on pixels (PenMode set to a
>negative number).
>
>In order to use this routine as a standard (ie override the Toolbox StdLine
>routine.) StdLine(newPt: Point) draws to the point specified by newPt.
>Your routine could take other arguments (line the SRGP routine) to specify
>the line style.  Or have a series of routines for each line style and use
>SetStdProcs(VAR procs: QDProcs) where:
>
>    Change the lineProc pointer to point to the line-drawing routine you
>need to draw the line style of your choice.
>
>There are a lot of possibilities, most of which involve a good deal of
>programming on your part.
>
>If anyone else has better ideas (I know there are much better ideas) please
>post them as I am quite the novice to Mac programming and would love to find
>some shortcuts for this kind of thing.
>                            _    _
>--
The quick and dirty trick that only works well for vertical or horizontal
lines is to set the pen pattern to one of the grays (depending on the
pattern you want).  In my applications, I've only needed dashed lines
for vertical or horizontal lines so this works ok.  But if you need lines
on arbitrary angles or curves, it will work pretty poorly.  Mostly this
might be needed in drawing, graphing or charting type of programs as far
as I can think of right now. (Depending on the pattern, this might work
ok for some angles.  Also, regularly changing patterns to different offset
grays can give the effect seen in the MacPaint marquee among many others...
Hope this is of help to someone.
Keith
[e-mail]
[e-mail]



- -------------------------

From: [e-mail] (Jess M Holle)
Subject:  drawing dash lines in QuickDraw...
Date: 29 Jan 92 04:07:36 GMT
Organization: Purdue University Engineering Computer Network

If this is just for screen display and just for lines, then it should be
possible to have a special Dotted_Line routine that draws the line as a
series of segments, with the endpoints of each line segment calculated by
the routine.  This would allow a parameter to the routine to specify the
length of each dash and the length of each blank desired.  I'm sure that
there are problems with this technique (esp. for printing), but for
onscreen lines, it should work.

Jess Holle



- -------------------------

From: [e-mail] (Michael Hecht)
Subject:  drawing dash lines in QuickDraw...
Date: 29 Jan 92 14:57:42 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail]
(Herve Trognon) asks:
> Is there any way to draw a dash line in quickdraw or do we have to
> implement it ourselves - and then how?

In article <[e-mail]>, [e-mail]
(Keith Warren Rickert) answers:
>
> The quick and dirty trick that only works well for vertical or horizontal
> lines is to set the pen pattern to one of the grays (depending on the
> pattern you want).  In my applications, I've only needed dashed lines
> for vertical or horizontal lines so this works ok.  But if you need lines
> on arbitrary angles or curves, it will work pretty poorly.

When I had to do this, I used a combination of two patterns. Each pattern
was a 4-pixel-wide stripe at opposite orientations, like so:

    P1:  *....***    P2:  ***....*
         **....**         **....**
         ***....*         *....***
         ****....         ....****
         .****...         ...****.
         ..****..         ..****..
         ...****.         .****...
         ....****         ****....

Since we're drawing line segments, we can calculate the slope of the line and
choose the appropriate pattern accordingly, like so:


void DashedLine( short h, short v )
{
    short dashPatID;


    /* Look at the slope by combining signs of h and v:
        same sign means negative slope;
        different signs means positive slope
        (remember: the Y axis is reversed from normal Cartesian in Mac grafPort)
    */
    dashPatID = ( h ^ v ) > 0 ? P2 : P1;

    /* Draw the line segment using the appropriate pattern */
    PenPat( *GetPattern( dashPatID ));
    Line( h, v );
}


If you're drawing a curve as a sequence of line segments, this method is quite
acceptable, since the appropriate pattern is chosen independently for each seg-
ment.

I've also supplemented this QuickDraw method with a PostScript method that gets
used when printing. In PostScript, I collect a series of line segments to form
a path, which I can then draw in a single stroke using the DashedLine PicComment.
The PicComments are arranged such that when printing to a PostScript printer,
the PS method is used and the above QD method is used when drawing to the screen
or to a QuickDraw printer.

If anyone wants a copy of the PostScript snippet, just send me mail.

--Michael

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT



- -------------------------

Subject:  drawing dash lines in QuickDraw...
From: [e-mail]
Date: 29 Jan 92 00:12:49 EST
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Thomas Alan Akins) writes:
> [concerning drawing dashed lines]
> There are a lot of possibilities, most of which involve a good deal of
> programming on your part.
>
> If anyone else has better ideas (I know there are much better ideas) please
> post them as I am quite the novice to Mac programming and would love to find
> some shortcuts for this kind of thing.

I wouldn't claim it's better, but drawing lines with a vertically or
horizontally stripped pattern works well (for horizontal or vertical lines,
respectively).

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o




---------------------------

From: [e-mail] (Jonathan Greenfield)
Subject: Finding all mounted volumes
Date: 28 Jan 92 02:36:29 GMT
Organization: CIS Dept., Syracuse University

How does one go about constructing a list of of all currently mounted
volumes?  (By vRefNum would be most convenient...but I can always convert
back to that.)

I'm interested in being able to search all of the desktop databases for
mounted volumes.  This is for System 7.

Thanks.

--
greeny                                           [e-mail]

"What's the difference between an orange?"



- -------------------------

From: [e-mail] (Mike Engber)
Subject:  Finding all mounted volumes
Date: 28 Jan 92 14:06:08 GMT
Organization: The Institute for the Learning Sciences

>I'm interested in being able to search all of the desktop databases for
>mounted volumes.  This is for System 7.

Here's a code frag (THINK C) that loops through all the volumes that
have DeskTop databases.

-ME

- -

/* Calls VPurgeDTDB for all mounted volumes */
static OSErr PurgeDTDB(OSType creator){
    VCB*    vcbPtr      = (VCB*)VCBQHdr.qHead;
    short   purgeCount  = 0;

    while(vcbPtr){
        OSErr                   err;
        HParamBlockRec          pb;
        GetVolParmsInfoBuffer   vParms;

        pb.ioParam.ioNamePtr    = NULL;
        pb.ioParam.ioVRefNum    = vcbPtr->vcbVRefNum;
        pb.ioParam.ioBuffer     = (Ptr)&vParms;
        pb.ioParam.ioReqCount   = sizeof(vParms);
        if(!PBHGetVolParmsSync(&pb) && ((1L<<bHasDesktopMgr) & vParms.vMAttrib)){
            switch(err=VPurgeDTDB(vcbPtr->vcbVRefNum,creator)){
                case noErr:
                    ++purgeCount;
                    break;
                case wPrErr:
                case vLckdErr:
                    /* vol locked - no worry - ignore */
                    break;
                default:
                    return err;
            }
        }
        vcbPtr = (VCB*)vcbPtr->qLink;
    }
    return purgeCount>0 ? noErr : -1;
}



- -------------------------

From: [e-mail]
Subject:  Finding all mounted volumes
Date: 29 Jan 92 05:02:40 GMT
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Jonathan Greenfield) writes:
> How does one go about constructing a list of of all currently mounted
> volumes?  (By vRefNum would be most convenient...but I can always convert
> back to that.)

Here's an XCMD that collects a list of mounted volumes:
unit GetVolUnit;
interface
  uses
    HyperXCmd;

  procedure Main (paramPtr: XCmdPtr);  {the entry point for the XCMD/XFCN}

implementation

  procedure Main (paramPtr: XCmdPtr);

    procedure GetVol (paramPtr: XCmdPtr);
      var
        err: OSErr;
        index: Integer;
        nameList: Handle;
        myHPB: HParamBlockRec;
        vName: Str255;

      procedure Fail (errMsg: Str255); {return an error message to HyperCard}
      begin {Fail}
        paramPtr^.returnValue := PasToZero(paramPtr, errMsg);
        Exit(GetVol);
      end; {Fail}

      procedure PutName (s: Str255); {add 's' to the nameList}
      begin {PutName}
        if PtrAndHand(pointer(ord(@s) + 1), nameList, length(s)) <> noErr then
          Fail('GetVol: out of memory')
      end; {PutName}

    begin {GetVol}
      if (paramPtr^.paramCount <> 0) then  {no parameters required}
        Fail('GetVol: no parameters required');
      nameList := NewHandle(0);
      if nameList = nil then
        Fail('GetVol: out of memory');
      index := 1;
      with myHPB do
        repeat
          ioNamePtr := @vName;
          ioVolIndex := index;
          err := PBHGetVInfo(@myHPB, false);
          if err = noErr then
            PutName(concat(vName, chr(13)));
          index := succ(index);
        until err <> noErr;
      PutName(chr(0)); {terminate list}
      paramPtr^.passFlag := false;
      paramPtr^.returnValue := nameList
    end; {GetVol}

  begin {Main}
    GetVol(paramPtr) {entry point}
  end; {Main}

end. {implementation}

The essential technique is indexed calls to PBHGetVInfo(). Hope this helps.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o



---------------------------

From: [e-mail] (Gregory G. Woodbury)
Subject: 68040 caches, why do programs break?
Date: 28 Jan 92 05:02:35 GMT
Organization: Wolves Den UNIX

The latest version of ToDo! (3.1) is system 7 compatible, but will not
run with the Q900 caches turned on.  Since the machine is slower than
molasses in february on mt washington with the caches off, the program
isn't worth using on the Quadra.

I'm told that the problem is that certain compilers (pascal generally)
try to be smart and generate what is essentially self-modifying code
that don't work with the 040 large caches.  It seems stupid to me that
any compiler would generate such a sequence.  Am I being uncharitable?

I'm also feeling a little dense :-)  are there other code constructs
that will break on a cache?
--
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: [e-mail]     [e-mail]
[The line eater is a boojum snark! ]           <standard disclaimers apply>



- -------------------------

From: [e-mail] (Steve Howell)
Subject:  68040 caches, why do programs break?
Date: 28 Jan 92 12:31:02 GMT
Organization: University of Tasmania, Australia.

[e-mail] (Gregory G. Woodbury) writes:

>The latest version of ToDo! (3.1) is system 7 compatible, but will not
>run with the Q900 caches turned on.  Since the machine is slower than
>molasses in february on mt washington with the caches off, the program
>isn't worth using on the Quadra.

Add to that list Microsoft Word 4 (and 5, from the looks of things) and
PageMaker, to name just a few...

>I'm told that the problem is that certain compilers (pascal generally)
>try to be smart and generate what is essentially self-modifying code
>that don't work with the 040 large caches.

Why would self-modifying code cause a problem? As I understand it, the 68040
supports both the write-through and copy-back cache architectures. In either
case, bus "snooping" should detect an access to main ram and mark the out-dated
cache entry as invalid, forcing the new data to be read from main ram into the
cache.  Is that not the case? (BTW, I agree that the generation of self-
modifying code is a dubious practice at best...)

Just curious.
Tim. (c/o:- [e-mail])



- -------------------------

From: [e-mail] (Robert Glen Rhode)
Subject:  68040 caches, why do programs break?
Date: 28 Jan 92 14:27:19 GMT
Organization: Rice University

In article <[e-mail]>, [e-mail] (Gregory G. Woodbury) writes:
>
> I'm told that the problem is that certain compilers (pascal generally)
> try to be smart and generate what is essentially self-modifying code
> that don't work with the 040 large caches.  It seems stupid to me that
> any compiler would generate such a sequence.  Am I being uncharitable?
>
> I'm also feeling a little dense :-)  are there other code constructs
> that will break on a cache?

Let me add another log to the fire here:
How can any "correct" cache coherency protocol allow the cache to
operate in any way which is different from non-cached?  Suppose you
have a program that, yes, modifies itself.  So the cache line that
got modified sets its "dirty" bit.  If you access it soon, it's still
in the cache.  If that cache line gets replaced, then the dirty bit
should be read, and that cache line should be written to memory.
This should all be done in hardware.  So where does the problem occur?

Just curious.

- Bob who will never be able to afford a 68040 anyway



- -------------------------

From: [e-mail] (Russell J. Davoli)
Subject:  68040 caches, why do programs break?
Date: 28 Jan 92 15:21:50 GMT
Organization: National Instruments Corp.

In article <[e-mail]>, [e-mail] (Robert Glen Rhode) writes:
>
> In article <[e-mail]>, [e-mail] (Gregory G. Woodbury) writes:
> >
> > I'm told that the problem is that certain compilers (pascal generally)
> > try to be smart and generate what is essentially self-modifying code
> > that don't work with the 040 large caches.  It seems stupid to me that
> > any compiler would generate such a sequence.  Am I being uncharitable?
> >
> How can any "correct" cache coherency protocol allow the cache to
> operate in any way which is different from non-cached?  Suppose you
> have a program that, yes, modifies itself.  So the cache line that
> got modified sets its "dirty" bit.  If you access it soon, it's still
> in the cache.  If that cache line gets replaced, then the dirty bit
> should be read, and that cache line should be written to memory.
> This should all be done in hardware.  So where does the problem occur?

The problem arises from the 68040 having big and separate data and code caches
that are copyback rather than write-through. When a program modifies code, say
in a jump table, the move instruction modifies a data word in the data cache.
However, if the program now tries to execute that code and the data hasn't
been written back to memory, then the instruction is fetched from memory
that hasn't been updated with the new code.  At this point, the CPU is
executing the wrong code, and probably no real code at all in the case of
a jump table.

It seems like it would have been helpful to tie the cache addresses in both
caches together in some so the 68040 would know when to flush the caches at
least, but this could be very expensive because each cache is 4K I think.

Before you flame Motorola, there may be a good justification for this.  In
UNIX systems, I don't believe that code is allowed to modify itself.  The
separate caches would be a boon here and wouldn't cause any problems.

--Russell Davoli ([e-mail])



- -------------------------

From: [e-mail] (Jim Cook)
Subject:  68040 caches, why do programs break?
Date: 28 Jan 92 16:39:10 GMT
Organization: Prime Computer, Inc.

In article <[e-mail]> [e-mail] (Russell J. Davoli)
writes:
>In article <[e-mail]>, [e-mail] (Robert
Glen Rhode) writes:
>>
>> In article <[e-mail]>, [e-mail] (Gregory G.
Woodbury) writes:
>> >
>> > I'm told that the problem is that certain compilers (pascal generally)
>> > try to be smart and generate what is essentially self-modifying code
>> > that don't work with the 040 large caches.  It seems stupid to me that
>> > any compiler would generate such a sequence.  Am I being uncharitable?
>> >
>> How can any "correct" cache coherency protocol allow the cache to
>> operate in any way which is different from non-cached?  Suppose you
>> have a program that, yes, modifies itself.  So the cache line that
>> got modified sets its "dirty" bit.  If you access it soon, it's still
>> in the cache.  If that cache line gets replaced, then the dirty bit
>> should be read, and that cache line should be written to memory.
>> This should all be done in hardware.  So where does the problem occur?
>
>The problem arises from the 68040 having big and separate data and code caches
>that are copyback rather than write-through. When a program modifies code, say
>in a jump table, the move instruction modifies a data word in the data cache.
>However, if the program now tries to execute that code and the data hasn't
>been written back to memory, then the instruction is fetched from memory
>that hasn't been updated with the new code.  At this point, the CPU is
>executing the wrong code, and probably no real code at all in the case of
>a jump table.

There is also another problem.  Storing to memory invalidates the data cache
but does not invalidate the instruction cache.  This means that even if the
modified instruction has actually made it out of the cache/write buffer to
memory, if the instruction to be executed is in the instruction cache, we
will take the stale entry out of the instruction cache rather than the most
current valid copy now in memory.  Again, the lack of tracking between stores
to memory needing to invalidate the instruction cache was a concious decision
to simplify the design, reduce the amount of circuitry, and increase
the performance of the 68040.  A lot of super-mini's and larger machines have
this limitation.  It's now migrating its way into micro's.

Jim
<[e-mail]>



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  68040 caches, why do programs break?
Date: 28 Jan 92 18:33:04 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] writes:

>I'm told that the problem is that certain compilers (pascal generally)
>try to be smart and generate what is essentially self-modifying code
>that don't work with the 040 large caches.  It seems stupid to me that
>any compiler would generate such a sequence.  Am I being uncharitable?

    Not really uncharitable, just misinformed. These days, no Macintosh
compiler generates self-modifying code sequences from high-level code. There
are occasions when programmers write such code sequences in assembly language,
and these will break when the 68040 caches are in copy-back mode, because the
code that's been modified in memory isn't in sync with the code that's in
the 040's instruction pipeline, so when the copyback happens, the modified
code gets smashed.

    There are some spots where "in-the-pipeline" code modification is
essential - for example, in the Mac Segment Loader, which virtually every
application uses. In the segment loader, code at the potential return
address (in the jump table) is modified, and it's necessary to flush the
cache before proceeding.

    Older versions of THINK C and THINK Pascal had a homegrown segment
loader for supporting multi-segmented code resources, drivers, and DAs, so
any segmented DA, driver, or code resource written with these (out-of-date)
versions will probably not work with the copyback cache.

    In a nutshell: any current 040 cache problems are likely to be the
result of code written in assembly language, not generated by a compiler.

R.


--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



---------------------------

End of C.S.M.P. Digest
**********************